"SFC /VERIFYFILE" doesn't work. Is it a BUG? (Network Steve Forum)

"SFC /VERIFYFILE" doesn't work. Is it a BUG?

Hello to all.

Original topic: hxxp://answers.microsoft.com/en-us/windows/forum/windows8_1-performance/sfc-verifyfile-doesnt-work-is-it-a-bug/17542cd5-1eee-4cb1-948c-d9ff68267e3a

I found that SFC /VERIFYFILE doesn't work on my machine.

I can't know if it doesn't work on each Windows 8/8.1 machine.

I saw this when I was trying to verify a well-known file prone to corruption (it is at least an year that this keeps to corrupt itself): CNBJ2530.DPB.

That file becomes corrupt for unknown reasons, from time to time.

Usually you can find Windows corrupt files through SFC /SCANNOW, wait for about half hour and check the CBS.LOG.

Given that the corrupt file is always THAT, I decided to try SFC /VERIFYFILE (few months ago), to save time.

To my surprise, it didn't work:

sfc /verifyfile=C:\Windows\winsxs\amd64_prncacla.inf_31bf3856ad364e35_6.3.9600.17415_none_95dd5540d57f8c01\Amd64\cnbj2530.dpb
Windows Resource Protection could not perform the requested operation.
(Italian: Protezione risorse di Windows: impossibile eseguire l'operazione richiesta.)

Yes, I used an elevated command prompt.

Yes, I've tried with double quotes... And single quotes, too.

The questions are: Doesn't it work just for me? Or Doesn't it work for everybody?

Thanks in advance for any replies and/or confirmations.

Operating System: Windows 8.1 x64 update 1.

- I changed the Windows font size from Control Panel\Appearance and Personalisation\Display, change the size of all items, larger (150%).

- I changed the setting NX=AlwaysOn (DEP always on), by:

bcdedit /set {current} nx AlwaysOn

- I modified the default rules of the firewall (I exported the standard criteria and saved in a file), created my own rules, blocked all outgoing connections (except those I created with my rules).

Edited by xilolee Wednesday, February 25, 2015 5:41 PM

February 25th, 2015 5:38pm

Hi Wanikiya and Dyami - ZigZag3143x and thanks for your answer.

Are you saying that command works on your system, even if the file is another one?

I have now tried that command on various files inside the c:\Windows\system32 folder, and it seems to work (and I'm partially happy :-) ).

Hence the questions are now:

- Should it only work for the files in c:\windows\system32 folder?

- Should it always fail for the files in C:\Windows\Winsxs\ folder?

Because the corrupted files are usually found in this one...

Edited by xilolee Sunday, March 01, 2015 12:08 AM

Free Windows Admin Tool Kit Click here and download it now

February 26th, 2015 4:10am

Hi Noel Carboni and thanks for your answer.

I already know how to substitute that file with a known good copy of it and that DISM solves the problem (after half hour of SFC and another half hour of DISM and another half hour of SFC, to check), and I also know that I can remove write permissions only on that file hence it won't become corrupted anymore.

The problem is about SFC that isn't able to check the files in the WINSXS folder (so I can check only THAT file, substitute it and re-check only THAT file, in 5 minutes instead of 1 hour and a half... The same is true for the files that aren't CNBJ2530.DPB, because I used it only as an example).

Edited by xilolee Saturday, February 28, 2015 10:58 AM

February 28th, 2015 10:55am

Hi Michael Shao and thanks for your answer.

"I think SFC command have its own usage (mostly it should be good to fix the files that needed to boot Windows), and not for all the repair of the component store files. Those files are considered repairable using DISM command"

Then it shouldn't check the winsxs folder at all.

Given that the SFC tool check the winsxs folder, the sfc /verifyfile should also do the same job.

See my point? :)

Best regards!

PS: the quotation system of this forum is horrible! :-|

Edited by xilolee 11 hours 44 minutes ago